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1.0 BACKGROUND 


The Landsat-0 CCT standards conmlttee has been examining Computer 
Conpatible Tape (CCT) fr.mats and format philosophies, with the objective of 
establishing some standard for CCTs which would promote Information exchange 
among remote sensing data users and would allow data from a variety of sources 
to be used for a given application. Format requirements were collected from 
menbers and a draft document of these requirements was prepared by the Canada 
Centre for Remote Sensing (CCRS). Hils document was presented to the CCT 
standards committee meeting In June, 1978, at NASA Goddard Space Flight 
Center (GSFC). Also, at this meeting, F.E. Guertin (CCRS) presented a pro- 
posed standardization methodology which responded to these requirements, and 
which Included an approach for bringing virtually all existing CCT formats 
.Into a CCT family of tape formats. 

Key to the CCRS approach is a concept which. In this document. Is 
referred to as a superstructure • a combination of precisely defined records 
and a method of employing them - which, when combined with any particular 
tape format, provides access to the data of that format without requiring 
specific knowledge of the particular format specifications. The concept won 
the general approval of the committee. It was decided that NASA, with the 
assistance of CCRS and Guertin, would produce an updated and expanded 
description of the superstructure and the CCT family of tape formats. The 
draft of this document was discussed and amended by the committee at a 
Septenber 26 through 28, 1978 meeting at GSFC. 
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2.0 PURPOSE 


The purpose of this document is to describe and define the tape 
format standardization approach recommended by the committee on CCT 
standardization. This approach applies to all types of remote sensing data 
user tapes. It should be noted that the purpose Is to address user tapes as 
opposed to production tapes which may have additional system-imposed 
requirements which were not addressed by the committee. 
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3.0 SCOPE 


TTie scope of this document Is fourfold: 

1. To present all rules and conventions required to employ the 
superstructure approach to the CCT family of tape formats for 
users of remote sensing data and producers of user tapes » 

2. To specify the superstructure records. 

3. To present the standard for future tape format desist which 
Is a guide to desisting the data records of a particular tape 
format, and 

. 4. To provide an example of how to Incorporate the superstructure 
Into an already established tape format. 


4.0 APPLICABLE DOCUMENTS 


t "User Computer Compatible Tape Format Family Requirements." 

Dated: TBO; Document Number: CCB-CCT-OOOI A 

e "Recorded Magnetic Tape for Information Interchange (6250 CPI* 
group-coded recording)." Dated: 1976; Document Nunber: ANSI 
X3. 54- 1976. 

e "Recorded Magnetic Tape for Information Interchange (1600 CPI» 
PE)." Dated: 1973; Document Number: ANSI X3. 39-1973. 

e "Interface Control Document between the Image Processing Facility 
and EOC Digital Image Processing System for Landsat for IPF/ 

EDIPS Computer Compatible Tapes (CCT*s)." Dated: 6 June 1977; 
Document Number: IPF-ICD-116. 

•a "Format for Digital Imagery on Magnetic Tape." EIA 
Engineering Dept.. Section 4.3.1. Dated: 18 January 
1978; Document Number: Standard Proposal 1296. 
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5.0 THE CCT FAMILY FORMAT STRUCTURE 


5.1 SUPERSTRUCTURE CONCEPT 

There are presently many existing CCT formats for remote sensing data. 
To provide for Interchangeability of these tapes among the users and producers 
of remote sensing data, a superstructure concept has been established. By 
adding the superstructure to any of the existing remote sensing data tape for* 
mats, the tapes will become part of the standard CCT format family and users 
will have the capability of performing basic processing (such as accessing and 
displaying) with the data without knowing the details of the Individual tape 
formats . 

The superstructure Is composed of tKO basic components, a volume 
directory which globally describes the configuration of the tape or tape set 
and file descriptors which describe In more detail the configuration of the 
files. The files are logically grouped on a tape or set of tapes and this 
group Is referred to as a logical volume. The Individual tapes are the physical 
volumes. The volume directory Introduces the logical volume and the file 
descriptor Introduces the file (see Figure 5-1). 

There are three types of records which comprise the superstructure: 
the volume descriptor, file pointer and file descriptor records, and the 
general structure of these records can be seen In Figure 6-1. Another record 


5-1 










type Is the text record which Is used with the superstructure concept to pro- 
vide any type of Information In human readable form. The first 12 bytes 
are standard and appear on each type of record. They contain a record number » 
a record type code (which also Includes sub- types) and a record length. The 
remainder of each record Is dependent on record type. The volume descriptor 
and file pointer records each contain a field which Is held free for utili- 
zation by the user. 

For a complete description and definition of superstructure records* 
see Section 6. 

5.2 SUPERSTRUCTURE RECORDS 

In the volume directory file there Is only one volume descriptor record 
and It Is always the first record of the file (unless a text record preceeds 
It). It contains three general types of Information: 1) the standard data* 
such as record number, type, length; 2) file-specific Information, such as num- 
ber of pointer records In the file; and 3) loglt-il-volume-speclfic Information. 
This third group of data Is the most extensive and contains all the Information 
which applies to the logical volume as a whole, such as data source Identifica- 
tion, physical volume Identification, and physical relationship of the logical 
volume to other logical volumes In the tape or tape set. (See Tables 6-1 and 
5-2.) This record gives the user enough Information to be able to locate the 
data In gross terms within the data tape set. Text records which contain 
additional Information relating to the logical volume as a whole or in general 
may be present In the volume directory file. 

The volume directory file also contains* for each of the remaining data 
files of the logical volume, a pointer record which points to the file and gives 
general Information about the data In the file. The standard Introductory data 
In the pointer record are followed by the Identifying and descriptive Infonnatlon 
on the referenced file and Its format. This Includes file number, name, number 
of records, record lengths, and Indication of the content of the file In terms 
of the type and format of the data. The file pointer records will allow a user 
to skip files and read only selected ones for perfoming rudimentary data pro- 
cessing. 
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Tht file descriptor record is the first record of etch file of the 
logical volume (except the volume directory file) and it describes with more 
detail the data in the records of the file. The record contains the standard 
introductory information (e.g.» record number, type, length) and infbrmation 
about the file (such as file number, name and file format) VhSich will vary from 
file to file. It also has a segment which contains further identification and 
description of the file format and content; however, the data elements and lay- 
out of this segment depend on the class (type) of data within the file. This 
segment is called the variable data segment. For each file class there is de- 
fined a specific variable data segment. The file descriptor record gives a 
user enough information tu access or display the data without requiring further 
specifications. ’ 

Text records begin with the standard introductory information (e.»., 
record number, type, length) and flags indicating the text is coded in ASCII or 
EBCDIC and whether the text continues on the next record. The remainder of the 
record can be used to write any desired alphanumeric information frr any purpose 
Text records can appear in any file. This type of record can be thought of as 
being similar to a Fortran comment card. 

Each of the superstructure records contains a record sequence number, 
the record length and type code. The record sequence number is located in 
bytes 1 through 4 of each record and its value starts at 1 and inci'eases se- 
quentially 1n the subsequent records of the file. Bytes 9 through 12 of each 
record contain the record length. For the superstructure records, record 
lengths are; 360 bytes for the volume descriptor record; 360 bytes for the file 
pointer record; and the same length as the other records In the file for the 
file descriptor record if the records are of constant length within the file, 
or 360 bytes if the record lengths within the file are variable. The record 
type codes, which appear in bytes 5 through 8, are used to identify the type 
of information contained in the record. 

There are four levels of type coding used by ti- superstructure, with 
one indicating the main type aid the others indicating the subtypes. The main 
type codes and \.heir data types are listed in Section 6.1. 
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5.3 


BASIC CCT TAPE LAYOUT 


The simplest and most common form of CCT Is the case where one physical 
volume (tape) contains one logical volume of data. A logical volume Is a set 
of data which Is grouped In any way that makes sense to the tape format designer 
(and presumably to the tape user). In terms of superstructure concepts, a 
logical volume Is a set of data which Is Introduced by a volume directory file 
and concluded with a null volume descriptor record (or the volume directory 
file of a succeeding logical volume). It may contain one or more data files, 
each Introduced by a file descriptor record. 

The data files contain the actual Information for which the CCT Is 
recorded, while the superstructure records direct the user to this data. The 
layout of a CCT of one physical volume containing one logical volume of N data 
files Is given In Figure 5.2. It starts with the volume directory file, which 
Is the Introduction to the logical volume and contains the volume descriptor and 
file pointer records. This Is followed by the data files. The files are 
separated by end-of-flle (EOF) Indicators, and the records within a file are 
separated by Inter- record gaps (IRGs). After the last data file, a null volume 
directory marks the end of the logical volume. It Is a file consisting of 
a null volume descriptor record only. 

If this particular tape (physical volume) Is associated with other 
tapes so that together they form a set (referred to as a volinne set), and If 
It Is not the last volume of the set, the null volume descriptor record Is not 
present and two EOFs Indicate that there Is no more data recorded on this tape. 

The two EOFs are referred to as an end-of-volume (EOV) Indicator. If this 
particular tape Is the last of a volume set or If It Is a single-volume set 
(I.e., tape Is not associated with other tapes as a set), the null volume 
descriptor record Is followed by three EOFs, which Is referred to as an end-of-set 
(EOS) Indicator. (Systems which are unable to detect three consecutive EOFs will 
have to determine which logical volume Is the last of a set by searching for 
the null volume descriptor record.) 
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TAPE UYOUT CONTINGENCIES 


^fffOINAL 

OF POO/} 


is 

QUAtiry 


Although recording one logical volume per physical volume Is the 
simplest of tape formats, there are many situations vfhich can make this Ineffi* 
dent or even Impossible. A discussion of some of these situations will depict 
the tape layout conventions which apply. 

5.4.1 Multl-Volune Recording 

Multl-voliane recording refers to recording a set of data which re- 
quires more than one physical volume. It generally Implies that the volumes 
are recorded consecutively at a given time and site. The data can be recorded 
In the one logical volume per physical voliane, as described, but when the 
length of the logical volume Is unknown at recording start time, or If the 
logical volinne Is s1rq)ly too long for one physical volume, the logical 
volune can be split between tapes. The logical volume may be divided between 
files, or when necessary between records within a file, although this second 
method Is not recommended. 

The method of splitting a logical volume on file boundaries Is 
Illustrated In the transition between physical Volumes 1 and 2 of Figure 5.3. 

The last file of Tape 1 Is followed by two EOFs (an EOV). The first file of 
Tape 2 Is the Volume Directory File. This Is the same file which appeared In 
Tape 1, with the exception that certain data fields have been updated (e.g.. 

Tape ID and. Physical Volune Number). One of the fields to be updated Is that 
Indicating the nunber of the first data file of the present physical volune. 

When splitting the logical volume between the Nth and (N+l)th files, as In 
the Illustration, this field would contain N>1 In the repeated volume directory. 
It Is this field which Indicates that this particular physical volume begins 
within a logical volume. 

An example of splitting a logical volume within a file Is Illustrated 
between Physical Volumes 2 and 3 of Figure 5.3. The last record of Tape 2 Is 
followed by two EOFs (an EOV). Tape 3 begins with the Volune Directory File - 
the same file which appears at the start of the logical volume on Tape 2, 
except that, once again, the proper data fields are updated. 
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PHYSICAL VOLUME 1 




PHYSICAL VOLUME 3 



FIGURE 5-3. ILLUSTRATION OF CCT FAMILY TAPE LAYOUT CONVENTIONS 
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This Includts • field In the file pointer record referring to the 
file being split and Indicating the record number of the first record of that 
file on this tape. It Is this field which Indicates that this tape begins 
within a file. After an EOF the second portion of the split file Is recorded 
without repeating the file descriptor record. 

5.4.2 Adding Data to a Previously Recorded Tape 

When adding data to a tape which already contains data» search for 
the null volume descriptor record* overwrite this record with a new volume 
descriptor record, add appropriate file pointer record(s), and then* after 
an EOF* record the new data files. Finally write a new null volume descriptor 
record followed by three EOFs. This procedure should be followed even when 
a small amount of data Is to be added. Each time this procedure Is followed 
a new logical volimie Is added to the tape. 

5.4.3 Use of Text Records 

The superstructure concept allows for text records to appear In any 
position In any file of a logical volume* although use of text records may be 
limited for particular applications (see Landsat-3 example* Section 9). There 
Is one highly recommended use of text records. When a tape contains more than 
one logical volume, a text record, appearing as the first record of the first 
file of the tape, could contain a simple description of the logical volumes on 
the tape and thereby serve as a "tape directory." 

Text records are of the same length as the other records of the file. 
If the other records of the file are not of equal length then text records are 
of 360 bytes In length. 


6.0 LAYOUT OF SUPERSTRUCTURE RECORDS 


This section defines the format and content of the three superstructure 
records— volwne descriptor, file pointer and file descriptor— and of the text 
record. 

6.1 GENERAL RECORD FORMAT RULES AND CONTENT 

The following rules apply to superstructure record format In general. 

1. The first 12 bytes (6 fields) of all records contain only 
binary numbers and predefined bit-pattern codes. 

2. The fields assigned to the first 16 bytes (8 fields) are 
similar for all four typos of records. 

3. From byte 13 to the end of record, fields are numeric or 
alphanumeric. Thay ore coded In ASCII or EBCDIC, with ASCII 
being the preferred code. 

4. Numeric strings are right -justified and alphanumeric 
are left- justified. 

5. In fields containing data and blanks, the blanks are the 
character blank (Jt) code in ASCII or EBCDIC. 

6. Data fields are assigned so as to follow 4 byte boundary 
alignments. 

7. Record lengths are a multiple of 180 bytes. 
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The 12 bytes referred to In rule 1 are Illustrated In Figure d*l. 

They contain record number, (1 field), record type and sub-type codes (4 fields), 
and record length (1 field). The record ninnber Is a 4 byte field which provides 
a binary sequentliil count of the records of a file. The first record of the 
file Is numbered one and the record number Increments by one per record. It Is 
right justified with the left-most bit being the most significant as indicated 
In the following diagram: 


Byte Number 

1 

2 

3 

4 

61 t Number MSB 

_87654321 

87654321 

87654321 

87654321 

Bit Weight 



2*3 

2^^ 

2^... 2® 


The next 4 bytes are assigned to record type codes and sub- type codes. 
The type code Is In byte 6. A code of 300)g In this byte Indicates the record 
Is one of the three superstructure records and a code of 077)g Indicates a 
text record. The first sub-type code (hierarchically and In recording order) 

Is in byte 5. In this byte, a code of 300)g Indicates a voliane descriptor 
record, a code of 333)g Indicates a file pointer record, and a code of 077)g 
indicates a file descriptor record. The second sub-type code Is In byte 7. 

In this byte a code of 077)g Indicates a null veliane descriptor record. All 
other sub-type code fields In superstructure records are coded 022)g at 
this time, which Is the default code. These 4 bytes for the various records 
are thus coded as follows (all codes given In octal value): 


Byte: 

5 

— 

7 

8 

Field; 

1*^ subtype 
code 

type 

code 

2®^ subtype 
code 

3*^ subtype 
code 

Volume descriptor 
record code: 

300 

30Q 

022 

022 

Null volume des- 
criptor record 
code: 

Hi 

300 

077 

022 

File pointer 
record code: 

333 

300 

022 

022 

File descriptor 
record code: 

077 

300 

022 

022 

Text record code: 

022 

077 

022 

022 
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For a discussion on assigning record type codes for the various records of 
the data files, see Section 7.3.1. 

Bytes 9 through 12 are reserved for the length of the record, 
given In bytes and coded In binary with bit weights as assigned to the four 
bytes for record number (above). For volume directory file recortis (volune 
descriptor and file pointer) this field Is used for verification purposes 
only since these records are always 360 bytes In length. File descriptor 
and text records, however, are sized to equal the length of the other records 
of the file In which they appear (assuming the file Is of constant record 
length; but If the records of the file are of differing lengths, the file 
descriptor and text records will be 360 bytes long). 

; The similarity of the next four bytes among superstructure records 

(rule 2) can be seen In Figure 6-1. The first two of these bytes (bytes 13 
and 14) are ASCII/EBCOIC flags. The next two (bytes 15 ^d 16) are blanks, 
except when used to Indicate the continuation of text on a following text 
record. These fields will be described on a per-record basis In the sections 
which follow. 

Rule 7, that record lengths are multiples of 180 bytes, does have 
an exception. If the file descriptor or text records occur In a file of 
records whose length Is not a multiple of 180 bytes, these records will Ik 
the same Idngth as the records In the file, rather than a multiple of 180 bytes. 

There Is a similarity among the three superstructure records In content 
as well as In format. The purpose of these records are to Identify, describe j 

and locate data In the data files. Thus, there are fields such as tape Identifi- 
cation (ID), logical volume generating country, and file name (Identifying); 
number of pointer records In volume directory, file class, and file data type | 
(describing); and physical volume number of start of logical volume, file number, 
and record code field location (locating). Thus superstructure records primarily 
supply Information about the data on the CCT, rather than carrying data themselves. 
All the fields of these records are defined In the following sections. 
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6.2 


THE VOLUME DESCRIPTOR RECORD 


The volume descriptor Is the first record of the volume directory 
file (unless preceded by text records). Its basic layout and content are 
Illustrated In Figure 6-1. After the f1r::it 16 bytes of general Information, 
the remainder of the record Is composed of four segments. The first gives 
format documentation and software Identification for the format In which the 
superstructure Is recorded on this tape. The second segment provides basic 
Information about the logical volume and gives the number of pointer records 
In the volume directory file. Since there Is one pointer record for each 
file In the logical volume, this also gives the number of files. The third 
segment Is spare, which Is reserved for expansion of control Information In 
future volume descriptor revisions. The fourth segment, the local use seg- 
ment, provides space for whatever notation or Information the tape user wants 
to carry with the volume directory. The Individual data Items of the volume 
descriptor record are listed In Table 6.1 and explained In Table 6.2. 
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TABLE 6.1 

VOLUME DESCRIPTOR RECORD 
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BYTE# 

DESCRIPTION 


>Nunter 

SEGMENT 

B 

1 


1-4 

llecord number 

B 

2 


5 

1st record subtype code, always 300)g ■ volume 
directory 

6 

3 


6 

Record type code, always - 300 ■ superstructure 

B 

4 


7 

2nd record sub-type code ■ 077} g If null volume 
descriptor, etherise this sub-type code ■ Q22)g 

3rd record sub-type code, always ■ 022)g 

B 

5 


8 

B 

6 


9-12 

Length of this record 

A 

7 


13-14 

ASCII/EBCOIC Flag for this file 


8 


15-16 

Blank 

A 

9 



17-28 

Superstructure control docinnent number 

A 

10 

1 j 


29-30 

Superstructure control document revision minber 

A 

11 

y 


31-32 

Superstructure record format revision letter 

A 

12 

1 

L 

33-44 

Software release number 

A 

13 



45-60 ** 

ID for physical volume containing this volume 
descriptor (tape ID) 

A 

14 



61-76 * 

Logical volume ID 

A 

15 



77-92 

Volione set ID 

N 

16 



93-94 

Number of physical volumes. In the set 

N 

17 



95-96 

Physical volume number, start of logical volume 

N 

18 



97-98 

Physical volume number, end of logical volume 

N 

19 

2 < 


99-100** 

Physical volume number containing this volume 
descriptor 

N 

20 



101-104** 

First referenced file number In this physical 
volume 

N 

21 



105-108 

Logical volume number within volume set 

N 

22 



109-112** 

Logical volume number within physical volume 

A 

23 



113-120* 

Logical volume creation date 

A 

24 



121-128* 

Logical volume creation time 

A 

25 



129-140* 

Logical volume generating country 

A 

26 



141-148* 

Logical volume generating agency 

A 

27 



149-160* 

Logical volume generating facility 

N 

28 



161-164* 

Nimiber of pointer records In volume directory 

N 

29 


< 

165-168* 

Number of records In volume o1 rectory 


30 

3 


169-260 

Volume descriptor spare segment 


31 

4 

- 

261-360 

Local use segment 


* Undefined In null volime descriptor. 

** Fields to be updated In a repeated volume directory. 
B ■ binary, A ■ alnhanumerlc, N ■ numeric 


Quality 


FIELDS 
1 thru 6 

7 

8 
9 


10 

11 


12 


13 


TABLE 6.2 

VOLUME DESCRIPTOR RECORD 
DATA FIELD EXPLANATIONS 

EXPLANATIONS 


As described In Section 6.1. 

The ASCII/EBCDIC flag Indicates If the alphamanerlc Infor- 
mation In the volume directory file Is In ASCII or EBCDIC. 
A code of AH denotes ASCII and EP Indicates EBCDIC. 

Two blanks. 

12 characters giving the Superstructure Format Control 
Document Identifying nuirdter, l.e.. the number of that 
dccwient which defines the current superstructure recorti 
formats and conventions - this doanent« 

2 characters Indicating the revision nimA>er or letter 
gf^^|n|uperstructure Format Control Document, I.e. « this 

2 characters Indicating the revision letter of the super- 
structure record formats. Initially coded |$A, this code 
updates one letter character, alphabetically, each time 
there Is a change to the format of a superstructure record 
(as opposed to a change to the control document which may 
not have been a change In actual record format). The 26th 
revision Is coded AA, the 27th AB, the 28th AC, and so on. 

12 characters Identifying the software version. The soft- 
ware referred to here Is that used to write this logical 
volume. The code is alphanumeric, left-justified code 
assigned by the producing facility. It Is updated for 
each modification. 


This Is a 16 character code also written or printed 
externally on the physical voliane and used to uniquely 
reference a particular CCT. This Identification Is the 
same for all logical volumes on the same physical volume. 
VIhen a logical volume spans physical volimes the code Is 
updated for the continuation physical volume(s). (Also 
referred to as tape ID.) 
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This Is a 16 character code supplied at the time the logical 
volume Is recorded and which can be used to uniquely refer- 
ence a logical volume within a volume set. 


TABLE 6.2 
(CONT'O) 


FIELDS 

15 


16 

17 


18 


IS 


20 


21 


EXPLANATIONS 

This Is a 16 character coda supplied at the time the first 
physical volume of a volume set Is recorded. It ensures a 
unique way to reference a volume set consisting of multiple 
physical volumes. 

This Indicates the total number of physical volumes In a 
volume set. A blank field Indicates that the Information 
Is not available at the time the logical volume Is recorded. 

This Indicates the sequence number of the physical volune* 
within a volume set* which contains the 1st record of the 
logical volume* A blank field Implies no specific sequence. 
The first physical volume Is numbered as 1. 

This will be the same as above unless the logical volume Is 
split across physical volumes. It Indicates the sequence 
within a volume set of the physical volume containing the 
last record of the logical volume. It should be coded 
blank If unknown at time of recording. 

This Is the sequence number within the volume set of the 
physical volume containing this volume directory file. If 
the logical volume Is completely contained within one physical 
volume this field will be coded the same as field 17. If It 
spans physical volumes* the volume directory Is repeated at 
the beginning of each tape containing part of the logical 
volume* and this field Indicates the tape nimd>er of the 
current physical volume. 

This field gives the file number within the logical volume 
of the first file which follows this volume directory. This 
can be larger than one Cthe number of the first data file 
of a logical volume) when a logical volume spans multiple 
Physical volimies. If a file spans two or more physical 
volumes each portion of the file Is referenced by the same 
number (because each portion Is using the same volume pointer 
record). Volume directory files are not Included In the file 
sequence number count. 

This Indicates the sequence number of the present logical 
volume within a volume set. Null volume descriptor Is 
Included In this count. The first logical volume Is denoted 
as 1. 
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FIELDS 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 


TABLE 6.2 
CCONT’D) 


EXPLANATIONS 


This Indicates the sequence number of the present logical 
volume within this physical volume. This ntmiber Is always 
present even In a null volume descriptor. The first logical 
volume Is denoted as 1. When a logical volume spans multiple 
physical volunes, the portion of the logical volume on this 
tape Is counted here as If It were an entire logical volume. 
This rule does not apply to field 21— logical volume number 
within volume set. 

This Is the date when the loci cal volume Is recorded, 
expressed In years, months and days. If multiple ‘logical 
volumes are recorded at different dates on the same physical 
volume, each logical volimie will reflect its own creation 
date. The code Is of the form: YYYYMW)D 

This Is the time when the logical volume Is recorded, 
expressed In hours, minutes and seconds. Due to the time 
required to record a logical volune It Is unlikely that 
two logical volumes will exhibit the sane time. The code 
Is of the form: HHHNSSXX— where XX Indicates hundredths 
of seconds. 

Name (or abbreviation) of country generating this logical 
volume. 

This specifies the laboratory or center responsible for the 
creation of the logical volume. 

This Identifies the computer facility on which the logical 
volume Is recorded. 

The number of pointer records In this volume directory. 

(This automatically Indicates the number of data files In 
the logical volume .J[ 

Total number of records In this volume directory. Equals 
number of pointers plus number of text records plus 1. 

This Is the portion of the directory which Is undefined 
and unused. It Is reserved for subsequent revisions. 

This Is the portion of the directory which can be used 
locally without having to satisfy any conmon and approved 
standard. Its purpose Is to meet local requirements that 
are not universally recognized. 
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6.3 THE FILE POINTER RECORD 

File pointer records reside In the volume directory Tile. There Is 
one file pointer record for each data file of the logical volume. These records 
are recorded In the same sequence as the files to which they point. 

The general record format and content of the file pointer record are 
Illustrated In Figure 6-1. After the first 16-bytes of general Information » 
there are three data segments. The first segment supplies Information which 
points to (locates) one particular data file. Indicates that file's format, 
and tells how to prepare to read the file. The second segment Is space and 
Is reserved for expansion of \!:d file pointer Information segment In future 
format revisions. The third sespnent provides space which the tape user mey 
use as desired. The Individual fields of the file pointer record are 
listed In Table 6-3 and explained In Table S-4. 
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TABLE 6.3 

FILE POINTER RECORD 


ORIGINAL PAGE IS 
OF POOR QUALITY 


XD 

Number 


BYTE # 

DESCRIPTION 

1 


1-4 

Record number 

2 


5 

1st record sub-type code ■ 333)g ■ pointer 

3 


6 

Record type code, always ■ 300)p • super- 
structure 

4 


7 

2nd record sub-type code » 022 )g 

5 


8 

3rd record sub-type code > 022 )g 

6 


9-12 

Length of this record 

7 


; 13-14 

ASCII/EBCDIC flag for the referenced file 

8 


15-16 

Blank 

9 

1 

17-20 

Referenced file number 

10 

I 

21-36 

Referenced file name 

11 

1 

37-64 

Referenced file class 

12 

1 

65-68 

Referenced file class code 

13 

1 

69-96 

Referenced file data type 

14 

1 

97-100 

Referenced file data type code 

15 

1 

101-108 

Number of records in referenced file 

16 

1 ' 
\ 

109-116 

Referenced file 1st record length 

17 

117-124 

Referenced file maximum record length 

18 


125-136 

Referenced file record length type 

19 


137-140 

Referenced file record length type code 

20 


141-142 

Referenced file physical volume number, start 
of file 

21 


143-144 

Referenced file physical volume number, end 
of file 

22 


145-152*** 

Referenced file portion, 1st record number 
for this physical volume 

23 

2 

153-260 

Pointer spare segment 

24 

1 

3 

261-360 

Local use segment 


*** Updated in repeated volume directory if logical volume is split 
within a file. 

V B * binary, A ■ alphanumeric, N « numeric 
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FIELD 
1 thru 6 

7 

8 
9 

10 


11 


12 




>nn O'’" 





TABLE 6.4 


FILE POINTER RECORD 
DATA FIELD EXPLANATIONS 


EXPLANATION 


As described In section 6.1. 

A 2-byte flag Indicating whether the alphanumeric data In 
the referenced file Is coded ASCII or EBCDIC. If ASCII* 
this field Is coded A|f; If EBCDIC. It Is coded EK. 

Two blanks 

Sequence number within the logical volume of the file 
referenced by this pointer. The first file following the 
volume descriptor Is file number 1. 

A 16 character name which Is the unique Identification 
provided when the volume directory Is created In order 
to specify the file referenced by the pointer. The name 
Indicates the nature of the file: header, annotation. 
Imagery, etc. 

This Is the description of the class to which the referenced 
file belongs. The class of a file Is based on the nature 
of Its content. The manber of classes should be open-ended 
but limited. Classes which are essential are: 

Alphanumeric and numerical lists 
Cellular or Image data 
Profile data 
- Polygon data 

Isolated data points. 

A file class Indicates a particular file format, and hence, 
knowledge of the class of a file leads directly to knowledge 
of that file's format. Each file class has a class code 
associated with It which Is given In the next field. 

A 4-byte code for the class described In field 11. 
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TABLE 6.4 (Cont.) 

FILE POINTER RECORD 
DATA FIELD EXPLANATIONS 

EXPLANATION 


This field Identified only the data; not the record 
Introduction (even If It Is not stored In binary or 
In the first twelve bytes) contained In the file 
through use of the following phrases: 

8 BIT ASCII ONLY 
EBCDIC ONLY 
BCD ONLY 
BINARY ONLY 

MIXED BINARY AND ASCII 
MIXED BINARY AND EBCDIC 
MIXED BINARY AND BCD 
UNDEFINED, ETC. 

Each data type has a code associated with It, which Is 
given In the following field (field 14). 

A 4-byte code for the data type described In field 13. 
These codes (given In the order of the phrases above) 
are: ASCO, EBCO, BCDO, BIND, MBAA, MBAE, MBAB, UNDF. 

This Indicates the number of records In the referenced 
file. If this number Is not known at the creation 
time, then this field Is blank. 

The length. In bytes, of the file descriptor record In 
the referenced file. 

This Is the length In bytes of the longest record In the 
referenced file other than the file descriptor record. 

This Is necessary to determine the memory requirement 
before accessing the file Itself. 

The types are: fixed length, variable length, undefined 
length, and length defined In the file descriptor. They 
are written as: FIXED LENGTH, VARIABLE LEN, UNDEFINED 
LE, and LENGTH IN FD. The size of fixed length records 
Is given by field 17. Variable length records are smaller 
than the maximum size described above and the actual size 
of each record Is defined in a fixed location In the 
record Itself. Undefined length records are smaller 
than the maximum size and the exact length Is not given 
In the format definition. It has t : be obtained from 
other sources. For some file classes, variable length 
records have lengths defined In the file descriptor 
record. 




TABLE 6.4 (Cont.) 

FILE POINTER RECORD 
DATA FIELD EXPLANATIONS 


FIELD 

19 

20 


21 


22 *** 


23 

24 


EXPLANATION 

A 4-byte code for the type described by field 18. The codes 
are: FIXD. VARE, UNDO, and LIFD. 

The number of the physical volume within the physical 
volume set containing the first record of the file. May 
be left blank If Information unknown at the time of 
recording. 

The number of the physical volume within the physical 
volume set containing the last record of the file. May be 
left blank If Information unknown at time of recording. 

When a portion of the referenced file Is on the previous 
physical volume, this number Is the record number of the 
first record of the referenced file to be recorded on this 
physical volume. In all other conditions the value Is one. 

This Is the portion of the pointer record which Is unde- 
fined and unused. It Is reserved for subsequent revisions. 

This Is the portion of the pointer record which can be used 
locally without having to :>at1sfy any common and approved 
standard. Its purpose Is to meet local requirements that 
are not universally recognized. 


Undated In repeated volume directory if the logical volume Is 
split within a data file. 
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6.4 


FILE DESCRIPTOR RECORD 


A file descriptor record Introduces each data file. The general 
record format and content of file descriptor records are Illustrated In 
Figure 6-1. Following the first l6-byte$ of general Information are four 
record segments. The first segment Identifies the documentation of the 
format of, and the software version used to produce, the data file of the 
particular application with which the superstructure Is being used. In 
other words, while the segment comparable to this In the volume descriptor 
Identifies current documentation of the superstructure formats, this field 
Identifies current documentation of the formats of the remainder of the records. 

The second segment provides the basic Information necessary to read 
this file (the file containing this file descriptor record.) The third segment 
Is the spare which Is reserved for expansion In future file descriptor revisions. 

The fourth segment Is referred to as the file descriptor variable 
segment. This Is because this segment varies with file class. Just as a 
particular file class Indicates a particular file format. It also Implies a 
particular file descriptor variable segment. The variable segment for a 
particular file format Is chosen from among existing variable segments If any 
apply, or else 1i Is defined at the time that the particular format Is designed. 
The layouts of variable segments which have already been defined are given In 
Appendix B.- These segments commonly start with parameters Indicating the 
number of records of each record type In the file. This Is followed with 
locator Information particular to the format of the data file, I.e., how 
to access and display essential data. 

The data fields of the file descriptor record (other than those 
of the variable segment) are listed In Table 6.5 and explained In Table 6.6. 
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FILE DESCRIPTOR RECORD 


Cu7 0(^F 


r— neir " 



DESCRIPTION OF POOR QUALITY 

Type y 

Number 

SEGMENT 

BYTE # 

B 

1 


1-4 

Record number 

B 

2 


5 

1st record sub- type code * 077)o ■ f^l« 
descriptor 

B 

3 


6 

Record type code, * 300)3 « super- 
structure 

B 

4 


7 

2nd record sub-type code ■ 022)g 

B 

5 


8 

3rd record sub-type code ■ 022)g 

B 

6 


9-12 

Length of this record 

A 

7 


13-14 

ASCII/EBCDIC flag for this file 


8 


15-16 

Blanks 

A 

9 



17-28 

Control document number for this embodlement 

A 

10 

1 i 


29-30 

Control document number for this embodlement 
revision nuiriber 

A 

11 


31-32 

File design descriptor revision letter * 

A 

12 



33-44 

Software release number 

N 

13 


> 

45-48 

File number 

A 

14 



49-64 

File name 

A 

15 



65-68 

Record sequence and location type flag 

N 

16 



69-76 

Sequence marker location 

N 

17 



77-80 

Sequence number field length 

A 

18 



81-84 

Record code and location type flag 

N 

19 



85-92 

Record code location 

N 

20 

2 < 


93-96 

Record code field length 

A 

21 


97-100 

Record length and location type flag 

N 

22 



101-108 

Record length location 

N 

A 

II 

23 

24 

25 



109-112 

113 

114 

Record length field length 

Flag Indicating whether Information resulting froi 
Image analysis Is Included within the variable | 
segment of this record 

A 



Flag Indicating whether Information resulting froii 
Image analysis Is Included within this file 

A 

26 

1 



115 

Flag Indicating that data display Information 
Is Included within the file descriptor record 

A 

27 


< 

116 

Flag Indicating that data display Information 
Is Included within the file In record(s) 
other than the file descriptor 


28 

3 

117-180 

Reserved segment 


29 

4 

181-end- 
of- record* 

File Descriptor Variable Segment 

L 


* Typically the file descriptor will be the same length as the remaining 
records of the file. If the file contains records of variable length* 
, tlM file descriptor yitll be 360 bytes In length* 

./s. — ^ ~ . — u. ' ^ 1/7- , 




TABLE 6.6 

FILE DESCRIPTOR RECORD 
DATA FIELD EXPLANATIONS 


FIELD 
1 thru 6 

7 

8 
9 

10 

11 


12 

13 

14 

15 


EXPLANATIONS 


As defined In section 6.1. 

The ASCII/EBCDIC flag Indicates If the alphanumeric data 
of this data file Is In ASCII or EBCDIC. A code of AH 
Indicates ASCII; of EH Indicates EBCDIC. 

Two blanks. 

12 characters giving the control document number of that 
document which defines this file format. 

2-bytes giving the revision number of the control document 
defining the current file format. 

2-bytes giving the revision letter of the file format (as 
opposed to revisions which affect the control docianent with- 
out affecting the file format). For a description of the 
lettering scheme* see field 11 of the volume descriptor 
record* Table 6.2. 

12 characters Identifying the software version. The soft- 

Sequence number of this file within the logical volume. 

The volume directory file Is not Included In this count. 

This Is the unique 16-character Identification of the present 
file as stated In the volume directory .file. 

This Is the flag which Indicates whether each record In the 
file has a sequence number* If the location Is fixed or 
variable* or If the count Is cyclical. The file descriptor 
Itself always has a sequence number. It Is not required 
for the other records. The allowed codes and their 
meanings are as follows: 

NSEQ-no known record sequence numbers present In the data 
records of the file. 

FSEQ-the record sequence number Is present In the same 
location In all data records of the file. 
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TABLE 6.6 

FILE DESCRIPTOR RECORD 
DATA FIELD EXPLANATIONS 
(CONT'D) 

EXPLANATIONS 


VSEQ*i'«cord sequence numbers are present In the data records 
of the file but tbeir locations vary from record to 
record. 

CSEQ-record sequence numbers are '*ot presenti but a cyclic 

counter Is present, I.e., each group of X records excluding' 
the file descriptor record in the file Is 
numbered 1 through X. 

If this field Is coded NSEQ or VSEQ, fields 16 and 17 are blank. 
If It is coded FSEQ or CSEQ, these fields are coded as follows. 

These eight bytes give the location of the start of the 
sequence number field. They give the record byte number 
of the first byte of the field. (It Is assumed that the 
record sequence number field falls on a byte boundary 
and consists of an Integral number of bytes.) 

4-bytes Indicating the length. In bytes, of the record 
sequence number field. 

This flag Indicates whether each record In the file has a 
record type code and If the location of the code Is fixed 
or variable. The file descriptor Itself always has a 
record code. It Is not required for the other records. 

The allowed codes and their meanings are as follows: 

NTYP-no known record type codes present In the data 
records of the file. 

FTYP-the record type code Is present In the same location 
In all the data records of the file. 

VTYP-the record type codes are present In the data records 
of the file but their locations vary from record to 
record. 

If this field is coded NTYP or VTYP, fields 19 and 20 are 
.blank. If It Is coded FTYP, these fields are coded as 
follows. 


TABLE 6.6 

FILE DESCRIPTOR RECORD 
DATA FIELD EXPLANATIONS 
(CONT'D) 


EXPLANATIONS 

These 8*bytes give the location of the start of the record 
type code field. They give the record byte number of the 
first byte of the field. (It Is assumed that the record 
type cooe field falls on a byte boundary and consists of an 
Integral number of bytes.) 

4-bytes Indicating the length, In bytes, of the record type 
code field. 

This flag Indicates whether each record of the file has Its 
record length recorded within the record, and If the loca- 
tion of the code Is fixed or variable. The file descriptor 
Itself contains a record length field. This Is not required 
for the other records. The allowed codes and their meanings 
are as follows: 

NLGT-no known record lengths present In the data records 
of the file. 

FLGT-the record length field Is present In the same location 
In all the data records of the file. 

VLGT-the record length fields are present In the data records 
of the file, but their locations vary from record to 
record. 

If this field Is coded NLGT or VLGT, fields 22 and 23 are 
blank. If It Is coded FL6T, these fields are coded as 
follows. 

These 8-bytes give the location of the start of the record 
length field. They give the record byte number of the 
first byte of the field. (It Is assumed that the record 
length field falls on a byte boundary and consists of an 
Integral number of bytes.} 

4-bytes Indicating the length. In bytes, of the record 
length field. 

This flag indicates whether Information resulting from Image 
analysis Is Included within the variable segment of this 
record. The code for yes"Y, no«N. 


TABLE 6.6 


FIELDS 

24 

26 

27 

28 
29 


FILE DESCRIPTOR RECORD 
DATA FIELD EXPLANATIONS 
(CONT'O) 


EXPLANATIONS 

This flag Indicatas whathar Information rasulting from 
Imaga analysis Is Includad within tha flla Itsalf. Tha 
coda for yas ■ Y, no ■ N. 

This flag Indicatas whether Information necessary to display 
tha file Is Included within tha variable segment of this 
record. The coda for yas-Y, no«N. 

This flag Indicates whathar Information necessary to display 
tha file Is Included within tha file Itself. Tha coda 
for yes»Y, no»N. 

60-bytes which ai'a held In reserve for expansion of file 
descriptor Information in future format revisions. 

The file descriptor variable segment. 
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6.5 


THE TEXT RECORD 

Whilt the text record Is not specifically a superstructure record, 
the superstructure concept provides for the use of text records. The format 
of text records Is very simple, as Illustrated by Figure 6*1. After the 
first 16-bytes of basic Introductory data, the remainder of the record Is 
free-form text. It may be used to carry any type of Information for any 
purpose, as long as It Is In alphanumeric code. It may appear In any position 
In any file (although this freedom of placement may have to be limited some- 
what for particular file formats-see section 8 for an example). In Its ability 
to float and to carry Information which Is not pre-defined, the text record Is 
analogous to the "comment" card used In Fortran programnlng. 

The data fields of the text record are listed In Table 6.7 and ex- 
plained In Table 6.8. 

The length of the text record obeys the following rules: In a fixed 
record length file It has the same length as the other records In the file; 

In a variable record length file It Is 360 bytes long. 

The text records can be used only In files for which the first 12 
bytes (6 fields) of every record are compatible with the text record's first 
12 bytes. 
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TABLE 6.7 
TEXT RECORD DATA 


rii^ 


iiliSI 


UMBER 


1 

2 


BYTE # 

DESCRIPTION 

1-4 

Record ninnber 

5 

1st record sub-type code ■ 022)g 

6 

Record type code • 077)g ■ text 

7 

2nd record sub-type code ■ 022 )g 

8 

3rd record sub-type code ■ 022 )g 

9-12 

Length of this record 

13-14 

ASCII/EDCDIC flag for this record 

15-16 

Continuation flag 

17-end-of 

record 

Field to be used for free-form text 


■ binary, A ■ alphanumeric 











FIELDS 
1 thru 6 

7 

8 
9 


TABLE 6.8 

TEXT RECORD DATA FIELD EXPLANATIONS 




EXPLANATIONS 


As described In section 6.1. 

A flag Indicating whether the alphanumeric Information 
of this record Is coded ASCII or EBCDIC. A code of 
AP Indicates ASCII; of EB Indicates EBCDIC. 

This field contains two blanks unless the Infonnatlon 
of this record Is continued on a following text record. 
In this case, this field Is coded CB. 

The remainder of this record Is reserved for alpha- 
numeric Information of any type for any purpose desired 
by the tape producer or tape user. It Is reconmended 
that the text message end with at least one null 
character. (The null character Is as defined for ASCII 
or EBCDIC.) 
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7.0 DESIGN STANDARD FOR FUTURE CCT FORMATS 


7.1 INTRODUCTION 

The CCT superstructure Is rigidly formatted and precisely defined. It 
Is also, of necessity.* very general In the sense that It can be appllM to a 
great variety of data/tape formats. It was designed In this manner In order 
to acconmodate as many existing and future remote sensing data formats as pos- 
sible. It Is highly desirable, however, to approach as nearly as possible one 
universal CCT tape format to be used for a11 future applications. 

Since future remote data sensing, manipulation and Interpretation 
techniques are unknown. It Is difficult to predict the form of future experiment 
data. It Is unreasonable to expect a format, for which data records have been 
defined to the precision to which the superstructure records haVe been defined, 
to be appropriate for all types of data. The method for satisfying the conflict 
In this situation Is twofold. First, define the superstructure which will allow 
for all the possibilities. Second, define a standard toward which all future 
particular tape formats wIM be designed. This standard would not state rules 
as to what Is permitted In the design, but rather what Is preferred. In this 
way an overall CCT universal tape format Is encouraged, with particular formats 
converging to the standard. 

The preceding sections of this document have defined the super- 
structure records, thus step one toward the solution Is satisfied. This 
leaves step two: define a standard for the design of future CCT formats. What 
does this entail? Since CCTs will contain superstructure records and r':ords 
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which we have referred to as data records, and since the superstructure 
records have already been defined, It Is clear that such a standard would 
have to address the definition of the data records. The superstructure concept 
also establishes certain basic tape organization procedures, but It does not 
address the ordering of what have been referred to as data files, nor does It 
address the organization of records within a data file. Thus, the formatting 
of these data files should also be covered by the standard. 

Designing what Is referred to as a particular tape format can be 
considered to Involve the following tasks: 

1. Decide vi^at grouping of data will compose a logical volume. 

This Is the highest level design decision and Is based solely 

on what would be a reasonable (logical) data grouping. It could 
Include, for example: one scene of Image data; one scene of 
Image data plus one associated land use classification map; 
data from one experiment from sensor tumron to sensor turn- 
off; etc. 

2. Group data of the logical volume Into files. This decision 
Is also based on what would be a reasonable data grouping. A 
very Important factor In grouping data Into files Is that the 
format of each resulting file should be one which will have as 
wide an application as possible, I.e. , that the format is not 
of a nature to restrict It to only rare or occasional use. 

3. Determine the types of records to be contained In, and their 
ordering In, each file. A prime consideration here Is that a 
record of a given type contain primarily one type of data. 

4. Define the specific record formats. 

5. Determine the class of each file format and define a file 
descriptor record variable segment for each. 

A standard for designing a tape format should provide a guide to 
these tasks. This guide Is presented In the following sections. 
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7.2 DATA GROUPING IN LOGICAL VOLUMES AND FILES 

7.2.1 Logical Volume 

While sets of related data are grouped physically In tapes and 
tape sets, the highest order of logical data grouping addressed by a par- 
ticular standard format Is the logical volume. While one or more logical 
volumes In one or more particular formats may be contained In one or more 
physical volumes, within each logical volume only one particular format 
applies. 

The relationship of logical volumes to one another on a tape or tape 
set, regardless of the data content of a logical volume. Is completely 
defined by superstructure conventions as described. In Section 5.4. Thus, 
when designing a format for a mission, project, sensor, etc., the logical 
volume Is the highest order of data organization that need be considered. 
Definition of the data content of a logical volume, or of data grouping Into 
logical volumes. Is a design decision for each particular format which must 
be based almost entirely on the nature of the data for which the format Is 
being designed. Because of this there Is very little which can be offered as 
a guide other than that a logical volume of data should be a stand-alone data 
set, I.e., should Include experiment data plus support and associated data 
required to make use of the data. This does not exclude the possibility of 
a logical volume of nothing but raw experiment data. If data In this form 
serve a purpose. 

7.2.2 File 

The Internal structure of a logical volume Is defined by the super- 
structure concept as defined In Section 5.3. It consists of a volume directory 
file (defined by the superstructure) and one or more data files. Once the 
data content of a logical volume has been determined. It then remains to group 
this data Into data files. This grouping of data Into files will establish 
the file format. 

The files within a logical volume may vary from being all of one 
format to being all of differing formats. The order of file types within a 
logical volume Is also to be established by the particular format. 
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A standard data file has a file descriptor as Its first record, as 
defined by the superstructure, and one or more other records of one or more 
record types. If more than one other record type Is present, the order In 
which the various record types appear Is also to be defined by the file format. 
Each resulting file format must have an associated file descriptor record 
variable segment. When designing a particular format, previously defined file 
formats (and their as:>cc1ated file descriptor variable se^nents) should be 
used whenever possible. When It is necessary to design a new file format. It 
Is desirable to Include as few record types as practical. 

7.3 RECORDS 

Once the basic organization of each type of file has been established. 
It remains to Jatermlne the type of records appropriate to carry the data, and* 
to define standard record formats. 

7.3.1 Record Types 

The concept of record type Is especially Important In records to be 
used In conjunction with the superstructure. All standard records have record 
type codes. When these codes are assigned In accordance with the standard 
guidelines, they will not only Indicate the type of data within the record, but 
will also become a code for the specific format of the record. Record codes 
thus become the lowest level of, and most precise vehicle for, format definition. 
And since all data on any CCT are in records, proper use of record codes along 
with the other basic superstructure concepts can completely define the format 
of any CCT. 

7.3. 1.1 Record Content. A standard record should contain one basic type 
of data, although associated information may also be Included. For example, 
a typical record of data from an earth scanning sensor may Include one scan 
line of Imagery plus calibration wedge values, a line quality code, a line 
Identifying code, border fill pixels, or other scan line associated support 
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information. This record is still considered an image data record. This 
method of segregating data of different types into different records is impor- 
tant since the nature of the basic data in the record is the initial factor 
in determining the record type code. 

7.3. 1.2 Record Type Coding . The record type code is actually made up of 
four separate one-byte codes, a type code and three sub-type codes. The 
type code indicates the basic data type of the record. The three sub-types 
are used to further classify the record data and format. Once a new record 
format has been designed, an appropriate four-code type code is assigned to it 
which will be unique to that format. 

7. 3. 1.2.1 Basic Record Type. In assigning record type codes, the first step 
is to choose one of the eight basic data type codes based on data type. The 
data types and the codes associated with them are as follows: 


DATA TYPE 

CODE 

DATA TYPE 

CODE 

Superstructure 

300), 

Ancillary 

044), 

Tape Directory 

OlDi 

Data 

355), 

Header 

022), 

Trailer 

366), 

Annotation 

333), 

Text 

077), 


In choosing the basic record type, the following guidelines should be 

followed: 

1. ' Superstructure - this is used with records of the superstructure 

(volume descriptor, file pointer, and file descriptor) only, 
and therefore is not an appropriate code for other CCT records. 

2. Tape directory - this record type exists in the present NASA Land- 
sat-3 tape format and so is Included in the design standard; how- 
ever, as the functions of the tape directory are included in the 
superstructure, further use of this record type is not reconmended. 

3. Header - header data are Informative in nature. Header records 
precede the actual data records and generally describe partic- 
ular data formatting and identification aspects of the data 
records to follow. 
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4. Annotation - this record type will contain data that Is Intended 
to be displayed along with sensor or experiment data on photo- 
graphic or graphic products. This type of data may be embedded 
In the actual data records or may be In records dedicated to 
annotation data only. This latter record type should be clas- 
sified as annotation. It may Include alphanumeric Information to 
be written on the product as well as other product feature data 
such as tick marks* borders* latitude and longitude indicators* etc. 

5. Ancillary - this classification Is broad and Includes support 
data for Image data. It may Include* for example* computer and 
experiment command and operation data* ephemerls and attitude^ 
data* transformation algorithms* ground control point Information* 
map projection data* etc. 

6. Data - for most remote sensing applications this record type 
will be most numerous as It will generally carry the actual 
sensor data. The basic data of these records will be actual 
Imagery or other experiment data which may be presented In an 
array* matrix* or other two-dimensional arrangement; or linear* 
string or one-dimensional experiment value series* or any data 
resulting from processing and analysis of experiment data. 

Data records typically also contain* In record leaders or 
trailers* support data associated with the data set of the record. 

It should also be noted that for purposes of photographic film 
recording* some data records may contain only annotation type data 

that will be exposed In the film recording process on the film 
product (e.g.* tickmarks* alphanumeric Information* borders* 
etc.)* and still be typed data since It Is to be treated as 
though It were Image data by the recorder. [It should be noted 
that although this record type Is very broad* It Is more speci- 
fic than the term "data record" which has been used up until 
this point to Indicate any record (other than file descriptor) of 
a data file.] 
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7. Trailer - this record type should be used only In the circum- 
stance where additional support data must be recorded after . 
(chronologically and physically In the tape layout) the actual 
sensor/experiment data. Use of trailer records Is discouraged 
except when system/processing constraints make it necessary. 

8. Text • the text record Is analogous to the "comnent" card con- 
vention. It may appear anywhere within a logical volume and 
does not affect the tape format. It contains alphanumeric 
(ASCII preferred) Information of any type and purpose desired. 


It Is assumed that every record of a CCT will have as a basic record 
type a code Indicating one of these eight classifications. 

7.3. 1.2.2 Record Sub-type Codes. The three sub-type codes are used to hier- 
archically sub-classify record types to finer and finer distinctions, until 
a complete 4-byte code uniquely Identifies a record format. The list of sub- 
type codes Is open-ended; however, new record sub- type codes must be approved. 
The sub-type codes which have been assigned to date Include the following: 


First Sub-type Codes 




Data Type 

Code 

Data Type 

Cod. 

Volume Descriptor 

300 )• 

File Descriptor 

077), 

File Pointer 

333 )• 

Default (no sub- 
type applicable) 

022), 

Image 

355 )• 



Ground Control 
Point 

Oil), 

Ephemerls/ 

Attitude 

366), 

Map Projection 
Second Sub-type Codes 

044), 

Radiometric 

Calibration 

077), 

Data Type 

Code 



Null (Volume 
Descriptor) 

077), 



Default 

022), 
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Third Sub-type Codes 

Data Type Code 

Default 022) ■ 

It should be noted that the order of the four codes within the overall 
record type code Is: 1) first sub-type. 2) basic record type. 3) second sub-type. 
4) third sub-type (see Section 8.3.2). For example, the code for a Land$at-3 
Image data record would combine the codes: 355) • (first sub-type. Image). 355) • 
(basic type, data). 022)i (second sub-type, default). 022)a (third sub-type) 
default) for a 4-byte record code of 355) • 355) • 022) • 022) «. 

Similarly, the code for a Landsat-D ancillary record of ephemerls/ 
attitude data would combine: 366) • (first sub- type, ephemerl s/attitude). 

044) • (basic type, ancillary), 022) • (second sub-type, default), and 

022) • (third sub-type, default) for a 4-byte record code of 366)$ 044)$ 022}$ 

022 ) ,. 

7.3.2 Record Formatting 

In formatting a particular record, there are two types of considera- 
tions established by this standard. The first Is of basic record construction 
conventions, and the second Is of the formatting of the data contained within the 
record. These are discussed below. 

7. 3. 2.1 Record Construction . A standard record Is a multiple of 180 bytes In 
length and begins with 12 bytes of Introductory data, as Illustrated In Figure 
7-1. If a record length of a 180-byte multiple Is not feasible, the record 
length should at least be a multiple of four bytes. After the 12-byte record 
Introduction, record format and content depend on record type. The 12 Introduc- 
tory bytes are defined as follows: 

• Record Number - a 4-byte binary number which Indicates the 
sequence of the record within the file. The first record of 
the file Is nimtered 1. and the record number Increments by 1 
per record. The record number Is binary and Is right- Justified 
and the left-most bit Is the most significant, as Indicated In 
Section 6.1. These are the first four bytes of the record. 
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Context 


Record Number 


1st Record Sub*type Code 


Basic Record Type Code 


Record Type Code 


2nd Record Sub-type Code 


3rd Record Sub-type Code 


Record Length 


FIGURE 7-1. A STANDARD CCT RECORD 
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• Record Type Code - This Is comprised of the four 1-byte 
codes described In Section 7.3.1. The byte asignments are: 
byte 5, first sub-type code*, byte 6, basic type code; byte 7, 
second sub- type code; byte 8, third sub-type code. 

* Racord Length - Each standard record has Its size In bytes 
recorded In bytes 9 through 12 for Internal verification purposes. 
This Is a binary, right-justified number with the left-most bit 
most significant, and with the bit numbers and weights assigned 
to these four bytes In the same manner as for the four bytes of 
the record number. 

7. 3. 2. 2 Data Formatting Consideration . The characteristics of remote sensing 
data are determined to a great degree by factors which are established previous 
to tape format design, such as sensor configuration, on-board data handling 
and ground data processing. These factors present constraints within which the 
format designer roust work, such as a required length In bits per pixel value 
and required number of pixels and other data grouping. There are» however, 
some basic guidelines which will be followed whenever possible In designing 
standard record formats. These are as follows: 

e Data groups should be multiples of 8-b1t bytes In length. 

All data fields should be aligned so as to fall on 4-byte 
boundaries. 

f Real and complex numbers may be given only In the formats Included 
In the EIA standard (see Applicable Documents, Section 4). 

e Pixel and other data group Justification, packing, etc., must be 
determined so as iiot to vary, at least within a file and prefer- 
ably within a logical volume. Codes for describing these factors 
should be Included In the file descriptor variable segment, 

t Alphanumeric data should, preferably, be coded In ASCII. 
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• Data from various sensors may be band-interleaved hy line 

or pixel) or band-sequential, but when pixels are of differ- 
ing resolution, they must either be adjusted to a common 
resolution or else they must be band-sequential . 

• Varying pixel length, due to data compression techniques 
or other causes, should be handled as separate classes of 
Image data files. 

7.4 DETERMINING FILE CLASS AND DEFINING THE FILE DESCRIPTOR 

VARIABLE SEGMENT 

The class of a file depends upon Its general format, which Is depen- 
dent on the type and ordering of data within the file. Since the purpose of 
the file descriptor variable segment Is to provide access to the file, files 
of the same class can be served by the same file descriptor variable segment. 

Once the format of a file has been established, which Includes defin- 
ing the type and ordering of records within the file, the first step is to 
decide whether any of the existing file classes/variable segments are appro- 
priate for the file. Those which exist at present are given In Appendix B. 

It should be noted that they are presented there In their generic form. When 
used with a particular format, fields such as "Number of records of group 1 
record type" become more specific, e.g., this field may become "Number of 
header records" or whatever record type Is appropriate for the pa**t1cular file. 
Also, fields defined In a variable segment may simply not be used for a parti- 
cular application. Compare the variable segments In Appendix B with those In 
the example In section 8 for further clarification of this distinction. 

If no existing file class/varlable segment Is appropriate for the new 
file format, a new class and variable segment must be designated. In doing 
this. It Is desirable to modify existing variable segments to meet new require- 
ments, or at least to pattern new segments on old ones. In any variable segment, 
the first 36 bytes should be reserved for Indication of the number of records 
of each type In the file. The preferred format Includes the following six 
parameter fields: 
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• Number of records of group 1 record type ( 6 bytes) 

- Length of group 1 record type records (6 bytes) 

Number of records of group 2 record type (6 bytes) 

- Length of group 2 record type records (6 bytes) 

• Number of records of group 3 record type (6 bytes) 

- Length of group 3 record type records (6 bytes). 

These 36 bytes should be reserved even If there are less than three types of 
records In the file. 

When determining what types of fields should be present In a given 
variable segment, the prime concern Is to direct a user to the data considered 
to be Important. In many Instances, use of ’’locators" will serve this purpose. 
A locator Is 16 bytes of Information which points to the field In the file 
which contains the desired Information. These 16 bytes are: 

Number of the record containing the field (6 bytes) 

- Field location within record, given by the record byte 
number of the first byte of the field (6 bytes) 

- Field size. In bytes (3 bytes) 

Field type; a code for the data type of the field such as: 

A • alphanumeric In ASCII or EBCDIC 
B - binary 

N • numeric In ASCII or EBCDIC. 

When a new file descriptor variable segment has been defined. It must 
be assigned a file class name of 28 characters and a file class code of 4 char- 
acters. These will appear In the file pointer records which reference files 
of this class (see Tables 6-3 and 6-4, field 11). 
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8.0 BRINGING EXISTING FORMATS INTO THE CCT FAMILY. 

AN EXAMPLE. 


The method for adapting existing CCT formats to the CCT family environ 
ment, which Is Illustrated In Figure 5.1, may perhaps be better understood 
through example. This section will show the modifications required for one 
such format, that of Landsat-3 CCTs, to be brought Into the CCT family of 
tape formats. This format Is specified by Interface Control Document (see 
Applicable Documents, Section 4) between NASA's Goddard Space Flight Center 
and the Department of Interior's Earth Resources Observation System Data Cen- 
ter. The Landsat-3 format was chosen because there are a relatively large 
number of remote sensing data users already familiar with this format, and 
because the break points for multl-volime sets are established by definition. 
Since the number of Landsat-3 data records per tape Is known, the exact 
number of superstructure records per volume set can be established. 

8.1 THE LANDSAT-3 FORMAT (WITHOUT THE SUPERSTRUCTURE) 

Without the superstructure, a Landsat-3 CCT tape set consists of from 
one to three physical volums, depending on the type of Imagery contained In 
the set. Each tape set contains one logical volume of data, and each physical 
volume starts with a tape directory. A logical volume consists of Imagery 
and associated data from one site and time, whether It Is a scene of one or 
more bands of Multi -Spectral Scanner (MSS) Imagery or a subscene of Return 
Beam Vldicon (RBV) imagery. An R6V logical volume has one Image data section 
preceded by a leader section containing scene attributes (headers, ancillary, 
annotation) and followed by a trailer section. MSS logical volumes will have 


one Image section (with leader and trailer) If only one band (one Image) of 
the scene Is present, or If the Imagery of the various bands 1.« Interleaved by 
line (the BIL format). If MSS Images are separated by band and presented se- 
quentially (the 6SQ format), the logical volume will contain as many Image 
sections (each with leader and trailer) as there are bands of Imagery present. 

These three cases are depictea In Figure 8.1. 

CCT files are followed by end-of-flle (EOF) marks. Tape directory, 
leader. Image, and trailer sections are thus fol owed by EOFs as shown in 
Figure 8.2. The nianber of records per file varies with sensor, interleaving 
and data correction, but the number of records per file Is known for each com- 
bination of these factors. 

Records of a given tape set are of a constant record length which Is 
established per sensor, except that the tape directory record Is always 360 
bytes. MSS records are 3596 bytes and RBV records are 5388 bytes. Records are 
separated by Inter-record gaps (IRGs). 

The last record of a physical volume Is followed by double EOFs; the 
last record of a tape set Is followed by triple EOFs. 

8.2 INCORPORATING THE SUPERSTRUCTURE 

To bring a particular format Into the CCT family of tape formats, 
essentially all that Is required Is to Insert the proper superstructure records 
In the proper positions. Two exanples of how this Is done are given In this 
section. The first cas« Is of a single-volume set with one Image section; the 
second Is of a three-volume set of five Image sections. 

For the single-volume case, the example format Is that for one band of 
geometrically uncorrected MSS Imagery. The superstructure records required are 
Illustrated In Figure 8.3. They are the volume descriptor ar.d four pointer records 
of the volume directory file, four file descriptor records, and the volume descrip- 
tor of the null volume directory file. The additional tape required for these six 
volume directory records (at 360 bytes each), four file descriptor records 
(at 3596 bytes), ten IRGs (at a nominal 0.6 Inches each) and two EOFs 
(at a nomir j 1 3.0 Inches each) are as follows: 
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FIGURE 8.1. LOGICAL VOLUME DATA FORMAT OF LAHOSAT-3 CCTs (WITHOUT THE SUPER! 
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Tape Directory 

E0F_ 

Header 

Ancinary 
Annotation 
EOF 

Image 

EOF 

Trailer 


EOF 



FIGURE 8.2. PLACEMENT OF EOFs 
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32.7 <n. 


4(3596 

81 


) j»> 6(360) b 
00 bytes/U. 


bytes 


+ 10 (0.6) In. + 2 (3.0) In. ■ 


at a recording density of 800 PBI» and 



+ 10 (0.6) in. + 2 (3.0) In. « 16.3 In. 


at a recording density of 1600 BPI. 

When these figures are compared with the 2,400 ft. of tape per CCT, 
and the approximately 1,020 ft. at 800 BPI and 570 ft. at 1,600 BPI required 
for the Image section alone, the additional tape required for the superstructure 
appears Insignificant. 

The example used for the triple volume set format Is that of five bands 
of BSQ, geometrically corrected MSS Imagery at 800 BPI (two volumes at 1600 BPI). 
The placement of superstructure records In this case Is Illustrated In Figure' 

8.4. The number of superstructure records required totals 84 (54 for the 1600 
BPI case). (It should be noted that when an Image section Is split between 
physical volumes each part constitutes a file which Is described by Its own file 
descriptor record. This Is not standard procedure, but Is necessary for Landsat-3 
due to the repeated tap>^ directory.) Calculating additonal tape required for the 
superstructure records In the same manner as above produces the following figures: 

Volume 1, 51.6 In. 9 800 BPI (44.3 In. 9 1600 BPI) 

Volume 2, 66.9 In. 9 800 BPI (39.6 In. 9 1600 BPI) 

Volume 3, 55.1 In. 9 800 BPI (only 2 tapes required 0 1600 BPI) 


Total additional tape required for the tape set, 173.6 In. 9 
800 BPI (83.9 In. 9 1600 BPI). 


While these numbers are higher per tape than the first example, the 
14 1/2 ft. total additional at 800 BPI and 7 ft. total additional at 1600 
BPI are still quite Insignificant when compared to the total tape required 
for the five Image sections, which Is 5660 ft. at 800 BPI and 2870 ft. at 
1600 BPI. 

The total additional records and tape required for various volume 
sets of Landsat-3 Imagery are given In Table 8.1. 
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FIGURE 8.4. EXAMPLE OF A VOLUME SET OF FIVE BANOS 
OF MSS IMAGERY AFTER ADDING SUPERSTRUCTURE RECORDS 




TABLE 8.1 

AODITIOIIAL RECORDS AND TAPE FOOTAGE REQUIRED FOR 
THE SUPERSTRUCTURE. BY VOLUME SET 


original Mac 

OF pooo 

QOALtry 





1uB*tr of 

Adoltlonal 
Taoa (ft.) 


Inagt Distribution by Dtnsity 

Additional 

RKords 

Par Voluna 
Sat 

Oatt Typt and 



800 n 

1~600 



Tapt Nua^r 

SCO BFI 

1600 BPI 

6PI 1 

1 

BPI 

800 BPt 

1600 8PI 

RSI 







GaeiMtr'lMlIy Uneorr«ct*d 
Ttpt 1 

2062 lints 

tntirt Inagt 

10 

10 

3.4$ 

2.63 

Tap# 2 

rtnalning 1«tgt lints 


11 




Gaorntrlcatly Corrtctad 
Tap# 1 

2661 Unas 

tntirt Inapt 

10 

10 

3. 46 

2.43 

Tap« 2 

2661 lints 


’ll 

* 



N5S BS£ 







GcoMtrleally Uncorraetad 
(1 band) Tap# 1 

tntirt lM 9 t 

tntirt Inapt 

10 

10 

3.16 

la6S 

(2 bands) Tapt 1 

band 1 

all Inapts 

\3 

16 

“s.PT" 

T62 

Tap# 2 

band 2 


14 




(3 bands) Tapt«l 

bands 1 and 2 

all Inapts 

19 

22 

6a94 

J.54 

Tapt 2 

band 3 


17 




(4 bands) Tapt 1 

bands 1 and 2 

all Inapts 

22 

28 

9al6 

4.46 

Tapt 2 

bands 3 and 4 


23 




(S bands) Tapt 1 

bands 1 and 2 

bands 1 • 2, and 3 

26 

28 

12.71 

7.01 

Taot 2 

bands 3 and 4 

bands 4 and 5 


26 



Tapt 3 

band 5 


24 




Gtomttrically Corrtctad 
(1 band] Tapt 1 

tntirt iMgt 

tntirt Inapt 

10 

10 

2.39 

1.70 

(2 bands) Tapt 1 

band 1 and 1491 lints 
of band 2 

all luapts 

16 

16 

5.63 

2.61 

Tapt 2 

1492 Unas of bind 2 


14 




(3 bands) Tapt 1 

band 1 and 1491 lints 
of band 2 

all Inapts 

19 

22 

6.59 

3.54 

Tapt 2 

1492 Unas of band 2 
and band 3 


20 




(4 bands) Tapt 1 

band 1 and 1491 lints 
of band 2 

bands 1 and 2 

. 

23 

22 

11.66 

$.88 

T#pt 2 1 

1492 lints of band 2 

bands 3 and 4 

23 

23 



and band 3 

1 





Tapt 3 

band 4 


22 




(5 bands) Tapt 1 

band 1 and 1987 lints 
of band 2 

bands 1» 2« and 3 

27 

28 

13.88 

7.01 

Tapt 2 

996 of 2, and band 3. 
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bands 4 and S 

29 

26 



Tapt 3 

1967 lints of band 4 
and band S 


28 




MSS Bit 







Gtonttrically Uncorrtcttd 
(4 bands) Tapt 1 

4600 Unas 

all lints 

9 

10 

3.75 

1.70 

Tapt 2 

4800 Unas 


9 




(S bands) Tapt 1 

4000 lints 

6000 lints 

10 

9 

$.44 

2.73 

Tapt 2 

4000 lints 

6000 lints 

8 

9 



Tapt 3 

4000 lints 


10 
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3976 lints 
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10 
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49’0 lints 

7460 lints 
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9 



Tapt 3 
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8.3 ASSIGNING FILE CLASS CODES AND VARIABLE SEGMENT FIELDS 

Prerequisite to employing the superstructure Is the definition of 
application-specific codes and fields, A file class and a variable segment 
must be defined for each different file format used In a particular format. 
These definitions for Landsat-3 are as follows In this section. 


There are four types of files In the Landsat-3 formats. Their 
names and codes are: 


Class Name 

Class Code 

File Content 

TAPE DIRECTORY 

TD|5)j 

Tape directory record 

LEADER FILE 

LEAD 

Header, ancillary, arid 
annotation records 

IMAGERY FILE 

IMGY 

Image data records 

TRAILER FILE 

TRAI 

Trailer Record 


Each of the four file types has a file descriptor record variable segment 
format. The variable segment Is 180 bytes In length for the tape directory 
file; It Is 3416 bytes for MSS and 5208 for RBV» for all other files. It starts 
In byte 181 of the file descriptor record. Since the purpose of the tape 
directory record Is superseded by the superstructure* It Is assumed that those 
accessing the tape via superstructure records will skip the tape directory 
file, and therefore, the tape directory variable segment Is simply 180 blanks. 
The variable segments for the other three files are listed and explained In 
Tables 8-2 through 8-7. 

The field and byte numbers In Tables 8-2 through 8-7 are relative to 
the variable segment. Field #1 and byte #1 of the variable segment are In 
fact field #29 and byte #181 of the file descriptor record. 
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TABLE 8-2. 

THE LEADER FILE VARIABLE SEGMENT (LANOSAT-3) 


rr field I Bvte « 1 

Description 

, 

Jm* 



N 

1 

1-6 

Number of header records 

N 

2 

7-12 

Header record length 

N 

3 

13-18 

Number of ancillary records 

N 

4 

19-24 

Ancillary record length 

N 

5 

25-28 

Number of annotation records 

N 

6 

29-36 

Annotation .record length 

A 

7 

37-52 

Scene Identification field locator 

A 

8 

53-68 

World Reference System (WRS) ID field 
locator 

A 

9 

69-84 

Mission Identification field locator 

A 

10 

85-100 

Sensor Identification field locator 

A 

11 

101-116 

Exposure date-time field locator 

A 

12 

117-132 

Image center field locator 

A 

13 

133-148 

Geometrlc/radlometrlc correction applied 
Indicator locator 

A 

14 

149-164 

Interleaving Indicator locator 

A 

15 

165-180 

Band(s) Indicator locator 

A 

le 

181-196 

Subscene Indicator locator 


17 

197-3416 (MSS) 
Or 5208 (RBV) 

Blanks 


* N ■ numeric, A • alphanumeric 
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TABLE 8-3. 

THE LEADER FILE VARIABLE SEGMENT EXPLAINED (LANDSAT-3) 


Field Explanation 

1 The number of header records In the file 

2 The length. In bytes* of header records, 

always 3596 for MSS or 5388 for RBV 

3 The number of ancillary records In the 

file 

4 The length. In bytes, of ancillary records, 

always 3596 for MSS or 5388 for RBV 

5 The number of annotation records In' the 

file 

6 The length. In bytes, of annotation records, 

always 3596 for MSS or 5388 for RBV 

7-16 While the first six fields of this segment 

provide actual Information, the remaining 
ten fields are locator fields which point 
to the position In the file where various 
Information can be found. The location of 
the desired field Is given In 16 bytes 
coded as follows: 

5 bytes - the record sequence number of 
bhe record containing the field 

6 bytes - the record byte number (referenced 
from the beginning of the record) of the 
first byte of the field 

3 bytes - length of the field In bytes 
1 byte - a code for the type of data fn the 
field. Cedes are 

A ■ alphanumeric In ASCII or EBCDIC 
B ■ binary 

N • numeric In ASCII or EBCDIC. 
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TABLE 8-3. 

THE LEADER FILE VARIABLE SEGMENT EXPLAINED (LANOSAT-3) Con'd 



Field 

7 

8 
9 

10 

11 

12 

13 


14 


15 


16 


17 


Explanation 

Location of the scene identification 

Location of the WRS Identification 

Location of the mission identification 

Location of the sensor identification 

Location of the image exposure date and 
time field 

Location of the field which gives the image 
in latitude/ longitude 

Location of the field which indicates whether 
radiometric and geometric corrections have 
been applied to the imagery 

Location of the field which tells if MSS data 
is band-interleaved by line or band-sequen- 
tial 

Location of the field which indicates which 
band(s) or image(s) are given in 
the image section * 

Location of the field which indicates which 
subscene or subimage is given in the image 
section. 

Blanks to fill the record. 
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TABLE 8-4. 

THE IMAGERY FILE VARIABLE SEGMENT (LANDSAT-3) 


1 F1g1(| 1 

Byte # 

Description 


N 

1 

I- 6 

Number of Image records 

N 

2 

7-12 

Image record length 


3 

13-36 

Reserved (blanks) 




Pixel Group Data 

N 

4 

37-40 

Number of bits per pixel 

N 

5 

41-44 

Number of pixels per data group 

N 

6 

45-48 

N'jnber of bytes per data group 

A 

7 

49-52 

Justification and order of pixels within 




data group 




Image Data In This File 

N 

8 

53-56 

Nimiber of Images (bands) 

N 

9 

57-64 

Number of lines per Image (excluding 




border lines) 

N 

10 

65-68 

Number of left border pixels per line 

N 

11 

69-76 

Total number of Image pixels allocated per 
line per band (Including pad pixels) 

N 

12 • 

77-80 

Number of right border pixels per line 

N 

13 

81-84 

Nimiber of top border lines 

N 

14 

85-88 

Number of bottom border lines 

A 

15 

89-92 

Interleaving Indicator 




Record Data In This File 

N 

16 

93-94 

Number of physical records per line 

1 

N 

17 

95-96 

(coded 0 If < 1) 

Number of physical records per multlspectral 




line 

N 

18 

97-100 

Number of bytes of prefix data per record 

N 

19 

101-108 

Number of bytes of Image data per record 

N 

20 

109-112 

Number of bytes of suffix data per record 


21 

113-116 

PrefIx/suffIx repeat flag 


*N ■ numeric 
A ■ alphanumeric 
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TABLE 8-4 cont'd 

THE IMAGERY FILE VARIABLE SEGMENT (LANOSAT-3) 


Field 

Byte 1 

Description 

389 

Number 



A 

22 

117-124 

Prefix/Suffix Data Locators 
Scan line number locator 

A 

23 

125-132 

Image (band) number locator 

A 

24 

133-140 

Time of scan line locator 

A 

25 

141-148 

Left-fill count locator 

A 

26 

149-156 

Right-fill count locator 

A 

27 

157-188 

Blanks 

A 

28 

189-196 

Scan line quality code locator 

A 

29 

197-204 

Calibration Indicator average values 

A 

30 

205-212 

locator 

Gain values field locator 

A 

31 

213-220 

Bias values field locator 


32 

220-252 

Blanks 

N 

33 

253-256 

Pixel Data Descrlotlon 
Number of left-fill bits within pixel 

N 

34 

257-260 

Number of right-fill bits within pixels 

N 

35 

261-268 

Maximum available data range of pixel 


36 

269-end of 

starting from 7.ero 
Blanks 



record 
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TABLE 8-5. 

THE IMAGERY FILE VARIABLE SEGMENT EXPLAINED (UNDSAT-3) 


Field 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 


16 

17 


18 


19 


Explanation 

Total numbers of Image records In the file 
Length of Image records, always 3596 for 
MSS or 5388 for RBV. 

A blank field required for consistency 
In variable segment formats 
Always 8 
Always 1 
Always 1 
Always blank 
The number of Images (bands) In this file 
Number of lines per Image (band) 

Always 0, see Appendix B for description 
Number of Image pixels per line 

Alloys 0 I Appendix B 

“ ( for description 

Always 0 j 

A code Indicating MSS data Interleaving 
BSQB ■ band sequential 
BILb ■ band Interleaved by line 
Number of physical records per line, 
always ■ 1 

Number of physical records per multlspectral 
line in this file, ■ 1 for MSS BSQ. 4 for 
MSS BIL, 1 for RBV. 

The length In bytes of the per-llne prefix 
support data field which Includes scan 
line ID, right and left fill count, etc. 

The number of bytes of Image data per 
record ■ 3548 for MSS, 5322 for Corrected 
RBV, 5375 for uncorrected RBV. 


See Appendix B 
for description 
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TABLE 8-5 cant'd 

THE IMAGERY FILE VARIABLE SEGMENT EXPLAINED (LANDSAT-3) 
Field Explanation 


20 

The number of bytes of suffix support 
data (following the Image data of a 
record) such as scan line quality code, 
gain and bias values, etc. 

21 

Always blank, see Appendix S for 
description. 

22-31 

Prefix/Suffix data locators • While all of 
the preceding fields give Information 
about the data In the Imagery file, the 
next eleven fields provide locators which 
point to the location of data within the 
Image records prefix or suffix. The lo- 
cation Is given In 8 bytes as follows: 

4 bytes - giving the byte number within 
the prefix or suffix which begins the 
field to located 

2 bytes - giving the length In bytes of 
the field to be located. 


1 byte - the letter Por S coded In this byte 
Indicates that the Infommtlon Is In the 
scan line prefix or suffix, respectively. 

1 byte - a code Indicating the type of 
data In the field. Codes are: 

A ■ alphanumeric In ASCII or lEiCDIC 
8 ■ binary 

N ■ mmerlc In ASCII or EBCDIC 

22 

Location of the scan line n^jmber 

23 

Location of the Image (band) number 

24 

Location of the time of the scan line 

25 

Location of the left-fill count 

26 

Location of the right-fill count 

27 

A reserved blank field 
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TABLE 8-5 conf d 

THE IMAGERY FILE VARIABLE SEGMENT EXPLAINED (LANDSAT-3) 


Field 

28 

29 

30 

31 

32 

33-35 


33 

34 

35 

36 


Explanation ^ 

Location of the scan line quality code 
Location of the calibration Indicator and 
wedge values 

Location of the gain values field 
Location of the bias values field 
Blank 

Pixel Data Description • the following 
three fields provide specific Information 
concerning the content of data value witnin 
a pixel 

Nund>er of left fill bits within each pixel 

Number of right fill bits within each pixel 

Maximum available data range of pixel starting fro 
zero 

Blanks to fill the record 
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TABLE 8-6. 

THE TRAILER FILE VARIABLE SEGMENT (LANDSAT-3) 



BYTE # 

DESCRIPTION 

H 

1 

1-4 

Number of trailer records 

H 

2 

5-12 

Trailer record length 


3 

13-36 

Reserved (blanks) 

A 

4 

37-52 

Parity error count field locator 

A 

5 

53-68 

Quality code sumnary inap field locator 


6 

69-3416 (MSS) 
or 5208 (RBV) 

Blanks 


* N » numeric, A » alphanumeric 
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TABLE 8-7. 

THE TRAILER VARIABLE SEGMENT EXPLAINED (LANDSAT-3) 



3 


4-5 


4 

5 

6 


Explanation 

The number of trailer records In the file 
The length. In bytes, of the trailer records(s) 
alM«ys 3596 MSS or 5388 for RBV 
A blank field required for consistency In vari- 
able se^nent formats 

Fields which give the location of Information 
In the trailer file. The location Is given 
In 16 bytes as described In Table 8-3, 
fields Ul5 

Location of the parity error count 
Location of the quality code map sunnary 
Blanks to fill the record. 
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APPENDIX A 
GLOSSARY 


ANSI 

ASCII 

Band 

8IL 

Bit 

BPI 

BSQ 

Byte 

CCRS 

CCT 

CPI 

Data file 


Data group 


American National Standards Institute 
American Standard Code for Information Interchange 
A collection of pixels representing a spectral portion of a scene. 
Band Interleaved by Line 

The smallest element of binary, computer-intelligible data. 

Bytes per Inch 
Band Sequential 

A unit of data consisting of eight bits. 

Canada Centre for Remote Sensing 
Computer-Compatible Tape 
Characters per Inch 

When used In conjunction with a superstructure concept, data 
file refers to the files of a logical volume other than the 
volume directory file, I.e., the files containing the data for 
which the tape Is being produced. 

The arrangement of data values and pad Into a group which Is 
aligned on byte boundaries, and which Is repeated throughout 
the experiment data section of the tape. See Appendix 6, Table 
B-4, fields 4 through 7. 

A-1 


Data record 


EOF 

EOS 

EOV 

File class 


File des- 
criptor 
record 

File des- 
criptor 
variable 
segment 

File 

pointer 

record 


Fin pixels 


Fixed length 
record 

Group 1 
records 

6SFC 


(1) Records of data files other than the file descriptor records. 

(2) One of eight basic record types - that carrying the experiment 
data. See Section 7. 3. 1.2. 

End-of-FIle marker 

End-of-Set marker, consists of 3 EOFs 

End-of-Volume marker, consists of 2 EOFs 

A file class Is comprised of a set of file formats which are 
similar enough to be accessed through one file descriptor 
variable segment. See section 7.4 and Appendix B. 

One of the three superstructure records. A file descriptor record 
Introduces and tells how to read a data file. See Section 6.4. 

That segment of the file descriptor record whose format Is 
dependent on file class. 

One of the three superstructure records. In the volume directory 
file, which Introduces a logical volume, there Is one file pointer 
record for each data file to follow. 

In a rectangular Image array, fill pixels complete scan lines 
of fewer Image pixels than the array width. Fill pixels have 
constant, preassigned values (e.g. black or white) while Image 
pixels contain sensor supplied data values. Due to Image skew 
(caused by earth rotation) and other factors, the number of fill 
pixels varies from scan line to scan line. 

A physical record contained In a file In which all of the physical 
records have the same record size by design. 

A general designation of records of the same type within a file. 
Goddard Space Flight Center 
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Image array 


Interleaving 


IRQ 

Left 

Justified 


Locators 


Logical 

volume 


LSB 

MSB 

MSS 

Multi spectral 
Line 

Multi -volume 
recording 

Multi -volume 
set 


Null volume 
directory 


A two-dimensional arrangement of pixels In a series cf lines 
creating a rectangular area which may contain. In addition to 
actual Image pixels, annotation data and fill pixels. 

The pattern In which pixels and lines of various bands are 
arranged (e.g., band Interleaved by line or band Interleaved 
by pixel). 

Inter-Record Gap 

Technique of positioning data so that the most significant bit 
appears In the leftmost position. 

A set of data fields found In file descriptor variable segi.ients 
which contain the Information necessary to locate particular 
Information In the remainder of the file. See Appendix B, Table 
2, fields 7 through 15; Table 4, fields 22 through 31; and Table 
6, fields 4 and 5. 

A logical collection of one or more related files recorded 
consecutively In a volume set. A logical volume may contain 
one or more than one physical file, but no file may span logical 
volimes. Logical volumes may span physical volumes, but are 
wholly contained within a volume set. 

Least significant bit 

Most significant bit 
Multi spectral Scanner 

A full scan line from each spectral band (Image). 

The recording of a logical volume which spans physical volumes. 
Techniques for doing this are discussed In Section 5.4. 

A tape set (volume set, physical volume set)_compr1sed of more 1 
than one tape (physical volume). 

J 

A volume directory file consisting of one volume descriptor 
and Indicating the end of a logical volume. See Table 6.1. 


A-3 


Physical 

record, 

record 


Physical 
volume, tape 


Physical 
volume set 

Pixel 

Pixel data 
group 

Pointer 

record 

Prefix data 


RBV 

Record 

Right 

Justified 


Scan line 


Scene 


Suffix 


A collection of data, In bytes, written to or read from a tape 
as a unit In a single operation. On tape, records are separated 
by Inter-record gaps (IRGs). 

A dismountable physical reel of magnetic medium. A physical 
volume may contain one, more than one. or less than one file. 

It may not contain partial records. The end of recording on 
a standard CCT physical volume Is Indicated by an end-of -volume 
(EOV) mark. 

See tape set. 

One Image sensor sample. 

A data group whose data values are pixels. 

See file pointer record. 

In an Image record, the support data which precedes the Image 
data (not to Include standard record Introductory data such as 
record number, type and length). 

Return Beam Vidicon 

See physical record. 

Technique of positioning data so that the least significant bit 
appears In the rightmost position. 

A full cross track sweep of an active detector (a full scene 
width). 

A delineated site which is spectrally divided Into one or more 
bands, or spaclally dividled Into subscenes. 

In an Image record, the support data which follows the Image 
data. 
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Super- 

structure 


Tape 

Tape set, 
volume set, 
physical 
volume set 

Variable 
data segment, 
variable 
segment 

Variable 

length 

record 

Volume set 


A combination of three precisely defined records (volume des- 
criptor, file pointer and file descriptor) and a methodology of 
how to employ them which will allow users to access the data of 
a tape without requiring knowledge of the particular tape format. 

See physical volume. 

A physical collection of one or more tapes (physical volumes). 


That segment of the file descriptor record (byte 181 to end of 
record) whose data fields are variable In that they depend on 
file class. 

A physical record contained In a file In which the physical records 
may have different record sizes. 

See tape set. 
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APPENDIX B 

FILE DESCRIPTOR RECORD VARIABLE DATA SEGMENTS 


File Class: LEADER FILE Class Code: LEAD 

This class of file precedes Image data files, supplying Information 
associated with the Image such as Image product annotation, ephemerls/attitude 
data, processing Information and other ancillary Information, 

The leader file variable segment gives the number of each type 
of record In the file and locates specific data fields within the file. It 
Is listed and explained In Tables B-1 and 6>2. 
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TABLE B-1 

THE FILE DESCRIPTOR RECORD VARIABLE 
SEGMENT FOR THE LEADER FILE 


Field 


Byte # 

Description 




N 

1 

1-6 

Number of group 1 records 

N 

2 

7-12 

Group 1 record length 

N 

3 

13-18 

Number of group 2 records 

N 

4 . 

19-24 

Group 2 record length 

N 

5 

25-30 

Number of group 3 records 

N 

6 

31-36 

Group 3 record length 

A 

7 

37-52 

Scene Identification field locator 

A 

8 

53-68 

World Reference System (WRS) Identification 
locator 

A 

9 

69-84 

Mission identification field locator 

A 

10 

85-100 

Sensor Identification field locator 

A 

n 

101-116 

Exposure date-time field locator 

A 

12 

117-132 

Geographic reference field locator 

A 

13 ■ 

133-148 

Image processing performed field locator 

A 

14 

149-164 

Imagery format Indicator locator 

A 

15 

165-180 

Band(s) Indicator locator 

A 

16 

181-196 

Subscene or subimage Indicator locator 


17 

1 

197-end 
of record 

Blanks 


*N ■ numeric, A ■ alphanumeric 


B-2 









TABLE B«2 

THE FILE DESCRIPTOR RECORD VARIABLE 
SEGMENT FOR THE LEADER FILE EXPLAINED 


Explanation 

Number of records of each of up to thrcic record types. 

It Is assumed that records of a given type are grouped 
together. This necessitates that text records be 
located at the end of the file. 

The number of group ^ (first record type) records In 
the file. 

The length, In bytes, of group 1 records . 

The number of group 2 records In the file. 

The length. In bytes, of group 2 records. 

The number of group 3 records In the file. 

The length. In bytes, of group 3 records. 

While the first six fields of this variable se^nent 
provide actual Information, the remaining ten fields are' 
locator fields which point to the position In the file 
where various Information can be found. The location 
of the desired field Is given In 16 bytes coded as follows: 

6 bytes - the record number of the record containing the 
field 

6 bytes - the record byte number of the first byte of the 
field 

3 bytes - length of the field In bytes. 

1 byte • a code for the type of data In the field. Codes 
are: 

A » alphanumeric In ASCII or EBCDIC 
B ■ binary 

N » numeric In ASCII or EBCDIC. 

Location of the scene Identification. 

Location of tht <»"!S Identification. 

Location of the mission Identification. 


TABLE B-2 (cont'd) 


Field Explanation 

10 Location of the sensor Identification. 

11 Location of the Image exposure date and time field. 

12 Location of the field which references the Image 

geographically . 

13 Location of the field which Indicates what processing 

has been performed on the Image data, e.g., whether 

radiometric and geometric corrections have been applied 
to the Imagery. 

14 Location of the field which tells If the data are band- 
interleaved by line, or band-sequential, etc. 

15 Location of the field which Indicates which Image(s) or band(s) 

Is (are) given In the Image set, and whether the Imagery Is 

16 Location of the field which Indicates which subscene or 

subimage Is (are) given In the Image set. 

17 Blanks to fill the record. 
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File Class: IMAGERY FILE 


Class Code: IM6Y 


This class of file contains the actual Image data. It may also 
contain per-llne support data such as quality codes» fill pixel counts, 
scan line Identification, etc. 

The Imagery file variable data segment gives the number and length 
of Image records; describes the data format In terms of the pixel group, 
the record content, and the overall Image; and gives the location of signi- 
ficant data fields In the record prefix and suffix. It Is listed and 
explained In Tables B-3 and B-4. 
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TA3LE B-3 

THE FILE DESCRIPTOR RECORD VARIABLE SEGMENT FOR 
THE IMAGERY FILE 


C?2?*<4 




n 

ELD 



Tyot* 

Number 

Byte 1 

Description 

N 

1 

1-6 

Number of Image records 

N 

2 

7-12 

Image record length 


3 

13-36 

Reserved (blanks) 

Pixel Group Data 

N 

4 

37-40 

Number of bits per pixel 

N 

5 

41-44 

Number of pixels per data group 

N 

6 

45-48 

Number of bytes per data group 

A 

7 

49-52 

Justification and order of pixels within data 
group 

Image Data In this File 

N 

8 

53-56 

Number of Images (bands) 

N 

9 

57-64 

Number of lines per Image (excluding border lines) 

N 

10 

65-68 

.Number of left border pixels per line 

N 

n 

69-76 

Total nun4>er of Image pixels allocated 
per line per band 

N 

12 

77-80 

Number of right border pixels per line 

N 

13 

81-84 

Number of top border scan lines 

N 

14 

85-88 

Number of bottom border scan lines 

A 

IS 

89-92 

Interleaving Indicator 

Record Data In This File 

N 

16 

93-94 

Number of physical records per line (coded 0 if <1 

N 

17 

95-96 

Numbers of physical records per multi spectral 
line 

N 

18 

97-100 

Length (In bytes) of prefix data per scan line 

N 

19 

101-108 

Number of bytes of Image data per scan line 

N 

20 

109-112 

Length (In bytes) of suffix data per scan line 

A 

21 

113-116 

Prefix/ suffix repeat flag 

Prefix/Suffix Data Locators 

A 

22 

117-124 

Scan line number locator 

A 

23 

125-132 

Image (band) number locator 

A 

24 

133-140 

Time of scan line locator 

A 

25 

141-148 

Laft-flll count locator 

A 

26 

149-156 

Right-fill count locator 






TABLE B.3 (cont'd) 


ORIGINAL PAGE IS 
OF POOR QUALITY 


1 Tm — 

Byte # 

Description 

Type* 




157-T^ 

Blanks 

A 

28 

189-196 

Scan Line quality code locator 

A 

29 

1 97-204 

Calibration Information field locator 

A 

30 

205-212 

Gain values field locator 

A 

31 

213-220 

Bias values field locator 


32 

220-252 

Blanks 




Pixel Data Description 

N 

33 

253-256 

Number of left-flllblts within pixel 

N 

34 

257-260 

Number of rlghi-flll bits within pixels 

N 

35 

261-268 

Maximum data range of pixel, (starting from o) 


36 

269-end 

Blanks 



of record 
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TABLE B-4 

THE FILE DESCRIPTOR RECORD VARIABLE 
SEGMENT FOR THE IMAGERY FILE EXPLAINED 


Field Explanation 

1 Total number of Image records In the file. 

2 Length of Image records. 

3 A blank field required for consistency In variable 
segment formats. 

Pixel Group Data 

When pixel values are not even byte multiples In length, 
either each pixel must be padded so as to have the value 
field length fall on byte boundaries, or the pixels must 
be grouped .u that the group of values plus padding fall 
on byte bCv;:::!ur1es. For example. If each pixel Is 10 
bits, the pIxeT group could be arranged as follows: 

Data Group 

^ 4 bytes ^ 

iOQXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

pad pixel 1 pixel 2 pixel 3 

The pixel group Is then repeated throughout the Imagery 
section. The pixel group of this file Is described In 
the following four fields. (A description of the data value 
content within each pixel Is given In fields 33»35, below.) 

4 Number of bits per pixel. 

5 Number of pixels per data group. 

6 Number of bytes per data group. 

7 Justification and order of pixels within data group. This 
Information Is given In code. The codes ai^ as follows; 

RJLR - the pixels Lre right justified (I.e. , the pad Is 
on the left) with the first pixel leftmost (I.e., 
pixel order Is from left to right), 

RJRL - the pixels are right justified with the first 
pixel rightmost. 

LJLR - the pixels are left justified with the first pixel 
leftmost. 
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TABLE B-4 (cont'd) 


Field 


8 

9 

10 

11 

12 

13 

14 

15 


Explanation 
Pixel Group Data 


,S 


LJRL - the pixels are left justified with the first pixel 
rightmost. 

)JJ6)6J4 - pixel value lengths fall on byte boundaries. 


Image Data 

The following diagram will be used as an example in ex- 
plaining the image data parameters. It represents a 

i~ 1 


-rr 

13 



scene of four bands of geometrically corrected (hence the 
skew) image data with borders. The numbers indicate the 
respective fields of the variable segment. 

The number of images (bands) in this file. 

Number of lines per image (band) (excluding border pixels). 

The number of border pixels to the left of the image pixels 
for each band (image). 

Total number of image pixels allocated per line or per band. 

The number of border pixels to the right of the image pixels 
for each band (image). 

The number of scan lines per image (band) of border above 
the image. 

The number of scan lines per image (band) of border below 
the image. 


A code indicating data interleaving. 

BSQJ6 - band sequential, one (o.* part of one) scan line per 
physical record 



Field 

BSnn 

BILK 

BInn 


BIPK 

BIPn 


16 Number of physical records per band (Image) per scan line 
(coded 0 If less than 1). This field Is not applicable to 
BIP Interleaving, and Is coded 0. 

17 Number of physical records per multlspectral line (BIL) may be 
less than one for multiple scan lines per physical record (BSnn), 
In which case It Is coded 0. This field Is coded 1 for BIPn 
Interleaving. 

18 The length of the prefix support data field associated with each 
scan line of each band (Image) which Includes scan line ID, 
right and left fill count, etc. For BIPn Interleaving, there 

Is only one prefix data area per physical record. 

19 The number of bytes of Image data per scan line per band. 

This Includes left and right borders. For BIPn Interleaving, 

It Is the total number of bytes of Image data within the record. 

20 The length of the suffix support data field associated with each 
scan line of each band (Image), such as scan line quality code, 
gain and bias values, etc. For BIPn Interleaving, there Is only 
one suffix data area pe** physical record. 

21 When the scan line requires more than one physical record 
this field will Indicate whether the prefix and suffix fields 
are repeated In each record. When they are not repeated they 
are zero-filled to maintain pixel alignment. 

RKKK means they are repeated. 

KKKK means they are not. 

22-31 Prefix/Suffix data locators - While all of the preceding fields 

give Information about the data In the Imagery file, the next 
eleven fields provide locators which point to the location of 
data within the Image record prefix or suffix. The location Is 
given In 8 bytes as follows: 

4 bytes - giving the byte number within the prefix or 
suffix which begins the field to be located. 

2 bytes - giving the length In bytes of the field to be 
located. 


TABLE B-4 (cont'd) 


ORIGINAL PAGE 18 
OF POOR QUALITY 


Explanation 

band sequential, nn scan lines per physical record 
band Interleaved by line, one (or part of one) scan 
line for one band (Image) per physical record 
band Interleaved by line, a maximum of nn bands 
(Images) per physical record, with only the last 
physical record of the multlspectral line being pad- 
ded on the right 

band Interleaved by pixel, one multlspectral scan line 
per physical record 

band Interleaved by n pixels, one multlspectral scan 
scan line per physical record. 


ii 


TABLE B-4 (cont'd) 


Field Explanation 

1 byte - the letter P or S coded in this byte indicates 
that the information is in the scan line prefix or 
suffix, respectively. 

1 byte • a code indicating the type of data In the field. 
Codes are: 

A « alphanumeric in ASCII or EBCDIC 
B ■ binary 

N « numeric in ASCII or EBCDIC. 

22 Location of the scan line number. 

23 Locatio'^ of the image (band) number. 

24 Location of the time of the scan line. 

25 Location of the 1eft>f111 count. 

26 Location of the right-fill count. 

27 A reserved blank field. 

28 Location of the scan line quality. 

29 Location of the calibration values indicator code. 

30 Location of the gain values field. 

31 Location of the bias values field. 

32 Blanks 

33-35 Pixel Data Desrription - the following three fields provide 

specific information concerning the content of data value 
within a pixel. 

33 Number of left fill bits within each pixel. 

34 Number of right fill bits within each pixel. 

35 Maximum available data range of pixel starting from zero. 

36 Blanks to fill le record. 
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File Class: TRAILER FILE 


Class Code: TRAI 


This class of file follows Image data files, carrying support data 
which imist be recorded after (chronologically and physically In the tape 
layout) the Image data. 

The trailer file variable segment gives the number and record 
length of trailer records, and the location within the file of the parity 
error count and quality code summary map fields. It Is listed and explained 
In Tables B-5 and B-6. 
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TABLE B-5 

FILE DESCRIPTOR RECORD VARIABLE SEGMENT 
FOR THE TRAILER FILE 


F1« 

fid 

Byte # 

Descrl Dtlon 

Type* 

Number 



N 

1 

1-4 

Number of trailer records 

N 

2 

5-12 

Trailer record length 


3 

13-36 

Reserved (blanks) 

A 

4-13 

37-196 

Reserved for locators 


14 

197-end 
of record 

Blanks 


*N » numeric, A » alphanumeric 
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TABLE B-6 

THE FILE DESCRIPTOR RECORD VARIABLE 
SEGMENT FOR THE TRAILER FILE EXPLAINED 


The number of trailer records In the file 

The length. In bytes, of the trailer record(s) 

A blank field required for consistency In variable 
segment formats 

Fields which give the location of Information In the 
trailer file. The location Is given In the bytes as 
described In Table B-2, fields 7*15 


Blanks to fill the record 


